Business models are often utilized as a blueprint to depict how a company should operate and develop. Depending on the tool utilized, business models may be portrayed in different forms. One of the more common ways of representing business process models is by means of workflow diagrams.
Business process models define business processes. Business processes describe activities that need to be performed within an organization. Examples of such activities may include processing purchase orders, payroll processing, or processing insurance claims. Actual software applications may be derived from business processes. These software applications, in conjunction with other software systems or team of humans, may accomplish a defined business process.
Creation of business applications results in a need for a comprehensive environment that will support the entire business application development process. The process may start with the building of business models and progress to representing the business models as object models. The next step may be creating source code for the business logic, that is, the creation of methods for the business processes that represent details of how the business runs. For example, if the business process is the handling of purchase orders, one detail about how this process is accomplished may be that purchase orders over $1,000 must be approved by a manager. The development process may then proceed to building and wrapping components (reusable pieces of code), building applications from the components, and installing the new applications and components into the appropriate environments.
The development process results in a further need to discover legacy systems, that is, existing applications, components, business processes, or other legacy systems, and integrate them into new business models which may in turn generate new business applications. The incorporation of existing legacy items into new applications will help preserve investments made in creating the legacy systems.
The current technology does not adequately address these needs. Although there are tools which allow implementation of parts of the development process, no one single environment exists which supports the process from beginning to end.
Another shortcoming of existing technology is the lack of ability to discover existing legacy items and incorporate them into new applications. Although there are tools that allow transformation of some legacy items into certain kinds of object models, these tools do not utilize the models to generate business applications. Furthermore, these tools are limited in their reverse engineering capabilities, and are also not generalized, meaning that they are able to transform only certain types of legacy items into object models.
Another reason why existing technology does not adequately support legacy integration is because of the lack of a defined method to exchange relevant information between object models. Object models are often created to define the business objects used by various business processes. But because there is no defined method of exchanging information between object models that utilize different object modeling methods, objects appearing in one model cannot be utilized in another modeling tool.
A further shortcoming of the current technology is the lack of tool and middleware independence in creating business applications. As an example of this shortcoming, if one tool is used to develop the business process model, one might be bound in the selection of the tools to create the application source code for the model. The lack of tool independence is mainly due to the inability to exchange information between tools.
Existing technology also does not allow specification and/or generation of source code for applications in a middleware-independent form. Thus, a component of an application built with one middleware cannot be automatically reused in a different environment with a different middleware.